Перейти к основному содержимому

7.07. Авторизация и аутентификация

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Инженеру

Авторизация и аутентификация​

В современных информационных системах управление доступом — неотъемлемый элемент архитектуры. Независимо от того, разрабатывается ли веб-приложение, мобильное приложение, корпоративная ERP-система или облачный микросервис, важно строго определять, кто пытается получить доступ к системе (аутентификация) и что ему разрешено делать (авторизация). Эти два процесса, хотя и тесно связаны, решают принципиально разные задачи и реализуются различными подходами, механизмами и протоколами.

Конфузия между аутентификацией и авторизацией — одна из самых распространённых ошибок даже среди опытных разработчиков. Да что уж, и я путал поначалу. Такая путаница ведёт к уязвимостям в системах безопасности, некорректному управлению правами и, как следствие, к серьёзным инцидентам: утечкам данных, несанкционированному доступу, повреждению инфраструктуры.

Данная глава призвана систематизировать знания об этих двух ключевых механизмах, детализировать их внутреннее устройство, рассмотреть архитектурные паттерны, распространённые протоколы и готовые решения, а также дать практические рекомендации по их корректной реализации в различных типах приложений.

1. Аутентификация: «Кто ты?»​

Аутентификация — это первый и обязательный этап контроля доступа, в ходе которого система устанавливает и подтверждает подлинность субъекта, инициирующего взаимодействие. В отличие от простого распознавания (identification), где субъект лишь заявляет о своей принадлежности (например, вводит логин), аутентификация требует предоставления доказательств, которые могут быть независимо проверены и верифицированы доверяющей стороной. Без этого этапа любые последующие проверки — в том числе авторизация, аудит или учёт действий — теряют основание: невозможно определить, кому разрешено или запрещено действие, если неясно, кто его совершает.

С технической точки зрения, аутентификация — это контролируемый процесс, включающий:

  • сбор заявляемых данных (идентификатора);
  • запрос и приём доказательств подлинности (факторов);
  • их верификацию в соответствии с установленной политикой;
  • выдачу подтверждения (например, в виде сессионного идентификатора или токена), которое может использоваться в последующих взаимодействиях.

Центральным элементом этого процесса является концепция фактора подлинности — независимого класса доказательств, основанных на одном из трёх фундаментальных принципов:

  • знание (что-то, что субъект знает — пароль, секретный вопрос);
  • владение (что-то, что субъект имеет — аппаратный ключ, временный код, устройство с доверенным окружением);
  • существование (что-то, что субъект есть — биометрический шаблон, поведенческий паттерн).

Ни один из этих факторов в отдельности не является абсолютно надёжным: знания могут быть угаданы или украдены, владение — скомпрометировано или утеряно, биометрия — подделана или скопирована. Поэтому в системах с повышенными требованиями к безопасности применяется многофакторная аутентификация (MFA) — принцип, при котором принятие решения о подлинности требует предъявления доказательств из минимум двух разных классов. Такой подход не устраняет уязвимости отдельных факторов, но создаёт асинхронный барьер: для компрометации всей цепи злоумышленнику необходимо одновременно преодолеть несколько независимых защитных слоёв, что резко повышает стоимость и сложность атаки.

Реализация аутентификации варьируется в зависимости от требований к безопасности, удобству использования, инфраструктурной зрелости и регуляторных ограничений. На одном полюсе — простые, но уязвимые схемы, такие как парольная или базовая HTTP-аутентификация, пригодные лишь для низкорисковых или изолированных сред; на другом — криптографически строгие протоколы вроде FIDO2/WebAuthn или сертификатная аутентификация по X.509, обеспечивающие высокий уровень доверия за счёт аппаратной привязки и отсутствия передачи секретов по сети.

Современные системы всё чаще отказываются от «самописной» аутентификации в пользу стандартизованных протоколов и готовых решений, поскольку даже незначительные ошибки в реализации (некорректное хэширование, отсутствие rate limiting, утечка сессионного идентификатора) могут привести к полному компрометированию учётных записей. При этом важно понимать: выбор протокола (OAuth 2.0, OpenID Connect, SAML) или платформы (Keycloak, Auth0, Entra ID) — это архитектурное решение, определяющее, как будет построена идентификационная основа всей системы — от интерфейса входа до интеграции с внешними сервисами и аудита событий безопасности.

Аутентификация — это процесс подтверждения личности пользователя или субъекта, пытающегося получить доступ к системе. Этот этап всегда предшествует авторизации и отвечает на вопрос: «Кто ты?».

В основе аутентификации лежит проверка одного или нескольких факторов подлинности:

  • Что-то, что вы знаете (например, пароль, PIN-код);
  • Что-то, что у вас есть (например, аппаратный токен, смартфон с приложением Google Authenticator);
  • Что-то, что вы являетесь (биометрические данные: отпечаток пальца, лицо, голос).

Сочетание двух и более факторов называется многофакторной аутентификацией (MFA). Она значительно повышает уровень безопасности, поскольку компрометация одного фактора (например, утечка пароля) не приводит к полному доступу злоумышленника.

Виды аутентификации​

  1. Парольная аутентификация
    Наиболее распространённый, но наименее защищённый метод. Основан на проверке пары логин/пароль. Без дополнительных мер (хэширование с солью, ограничение попыток, MFA) уязвима к брутфорсу, фишингу и утечкам баз данных.

  2. Базовая аутентификация (Basic Authentication)
    Реализуется передачей логина и пароля в заголовке HTTP-запроса в закодированном виде (Base64). Не рекомендуется в чистом виде без шифрования TLS, так как данные легко декодируются. Используется в тестовых средах или внутренних API с ограничениями трафика.

  3. Биометрическая аутентификация
    Основана на уникальных физиологических или поведенческих характеристиках. Требует надёжного хранения шаблонов и защиты от подмены (например, фото вместо лица). Применяется в мобильных устройствах, системах физического доступа.

  4. Сертификатная аутентификация
    Использует X.509-сертификаты для подтверждения подлинности клиента. Применяется в корпоративных и высоконадёжных системах, где требуется строгая идентификация без участия пользователя.

  5. Токен-ориентированная аутентификация
    Использует криптографически подписанные токены (например, JWT) для передачи идентификатора пользователя и его атрибутов. Подробно рассматривается в разделе о JWT.

  6. Протокольная аутентификация
    Включает такие стандарты, как:

    • OAuth 2.0: в первую очередь предназначен для делегирования доступа, но часто используется и для аутентификации (через OpenID Connect).
    • OpenID Connect (OIDC): надстройка над OAuth 2.0, специально созданная для аутентификации. Позволяет использовать внешние провайдеры (Google, Microsoft и др.).
    • SAML (Security Assertion Markup Language): XML-стандарт для единого входа (SSO), широко применяемый в корпоративных средах.
    • Kerberos / NTLM: протоколы, используемые в Windows-доменах для аутентификации в закрытых сетях.

Готовые решения​

Для сокращения времени разработки и повышения уровня безопасности рекомендуется использовать проверенные платформы:

  • Auth0 — облачный Identity-as-a-Service (IDaaS) с поддержкой множества протоколов.
  • Firebase Authentication — простая интеграция для веб- и мобильных приложений с поддержкой социальных провайдеров.
  • Keycloak — open-source решение с поддержкой OAuth 2.0, OIDC, SAML, ролевой модели и расширенной настройки.
  • Azure Active Directory (Entra ID) — корпоративное решение Microsoft, интегрируемое с Office 365, Windows и Azure-сервисами.
  • Okta — коммерческая платформа с мощным UI, жизненным циклом пользователей и MFA.

2. Авторизация: «Что тебе разрешено?»​

В информационных системах принцип наименьших привилегий (Principle of Least Privilege) предполагает, что любой субъект — будь то человек, программный агент или устройство — должен обладать ровно тем объёмом прав, который необходим и достаточен для выполнения его текущей задачи, и ни более того. Реализация этого принципа невозможна без чёткого разделения двух фундаментальных процессов: аутентификации — установления идентичности субъекта, и авторизации — определения, какие действия этот субъект уполномочен совершать в отношении конкретных ресурсов системы.

Если аутентификация отвечает на вопрос «Кто ты?», то авторизация отвечает на «Что тебе разрешено?». Это самостоятельный, логически и временно последующий этап контроля доступа, выполняемый только после успешного подтверждения подлинности субъекта. Без верифицированной идентичности любая проверка прав теряет смысл: нельзя разрешать или запрещать действия лицу, чья принадлежность не установлена.

С точки зрения архитектуры, авторизация — это процесс принятия решения о допустимости операции на основе трёх компонентов:

  • субъекта (subject) — того, кто инициирует запрос;
  • объекта (object) — того, к чему запрашивается доступ (файл, API-метод, настройка, данные);
  • действия (action) — того, что субъект намерен сделать с объектом (чтение, запись, исполнение, удаление).

Это решение принимается в рамках так называемой модели управления доступом (Access Control Model) — формализованной схемы, определяющей, каким образом права субъектов связываются с объектами и как интерпретируются условия доступа. Выбор модели критически влияет на выразительную мощность, гибкость, производительность и управляемость системы. Некоторые модели ориентированы на простоту и масштабируемость (например, в корпоративных приложениях), другие — на тонкую настройку под динамические и контекстно-зависимые сценарии (например, в облачных или регулируемых средах, где требуется соответствие GDPR, HIPAA или ФЗ-152).

Важно понимать, что авторизация — это динамический процесс, в котором могут участвовать как предварительно рассчитанные правила (например, назначенные роли), так и условия, вычисляемые в момент запроса (например, геопозиция клиента или состояние MFA). Поэтому современные системы всё чаще комбинируют несколько подходов: базовый уровень — RBAC для упрощения администрирования, дополненный атрибутивными и политико-ориентированными проверками для реализации сложных сценариев.

Если аутентификация отвечает на вопрос «Кто ты?», то авторизация отвечает на «Что тебе разрешено?». Это процесс проверки прав доступа субъекта (пользователя, сервиса, устройства) к объекту (файлу, API-эндпоинту, функции).

Авторизация выполняется после успешной аутентификации. Без подтверждённой личности проверка прав не имеет смысла.

Модели управления доступом​

Существует несколько ключевых моделей авторизации, каждая из которых подходит для определённого класса систем:

  1. RBAC (Role-Based Access Control)
    Доступ определяется через роли. Пользователь назначается одной или несколькими ролями, а каждой роли присваивается набор разрешений (permissions).
    Пример: Роль admin может удалять пользователей, роль user — только просматривать профиль.

  2. ABAC (Attribute-Based Access Control)
    Доступ определяется на основе атрибутов: пользователя (отдел, должность), ресурса (категория, владелец), среды (время суток, геолокация, IP-адрес).
    Пример: Пользователь из отдела «Финансы» имеет доступ к документу «Бюджет», если время запроса — в рабочие часы и IP принадлежит корпоративной сети.

  3. PBAC (Policy-Based Access Control)
    Более обобщённый подход, где доступ управляется политиками — логическими правилами, которые могут включать условия из ABAC, временные ограничения, контекст устройства и т.п.
    Пример: «Доступ к административной панели разрешён только с доверенного устройства и только при включённой 2FA».

  4. ACL (Access Control List)
    Классический подход: у каждого ресурса есть список, где указано, какие субъекты имеют к нему доступ и с какими правами. Гибок, но трудно масштабируем при большом числе пользователей и ресурсов.

Механизмы авторизации​

  • Списки разрешений (Permissions)
    Минимальная единица контроля доступа. Например: read:documents, write:users, delete:posts. Комбинируются в роли или политики.

  • Делегирование доступа
    Пользователь может временно передавать свои права другому субъекту (например, через OAuth). Это особенно важно в SaaS-системах и интеграциях.

  • Сессии и токены
    После аутентификации система должна каким-то образом помнить, что пользователь уже прошёл проверку. Это реализуется через:

    • Сессии (сервер хранит состояние в памяти или БД, клиент получает session ID в cookie);
    • Токены (клиент хранит состояние, сервер проверяет подпись и содержимое токена — stateless подход).

3. JSON Web Tokens (JWT): архитектура и применение​

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), предназначенный для компактной и безопасной передачи утверждений (claims) между двумя сторонами. JWT часто используется как механизм аутентификации и авторизации в stateless-приложениях, особенно в RESTful API и микросервисных архитектурах.

В современных распределённых системах, где клиенты и серверы взаимодействуют по протоколу HTTP — изначально stateless-протоколу, — возникает фундаментальная задача: как идентифицировать запросы, принадлежащие одному и тому же субъекту (пользователю, системе или сервису), при отсутствии встроенного механизма сохранения состояния между обращениями. Традиционно для решения этой задачи использовались серверные сессии: при аутентификации сервер создавал запись состояния (например, в памяти или базе данных), а клиенту выдавал идентификатор сессии (обычно в виде cookie), по которому сервер при каждом последующем запросе извлекал контекст. Такой подход, несмотря на простоту, обладает рядом ограничений: необходимость хранения и синхронизации состояния усложняет горизонтальное масштабирование, повышает потребление ресурсов и вносит дополнительные задержки при обработке запроса.

В ответ на эти вызовы был разработан альтернативный подход — stateless-аутентификация, в основе которой лежит идея передачи всего необходимого контекста непосредственно в теле запроса, без сохранения состояния на стороне сервера. Именно в этом контексте и появился JSON Web Token (JWT) — открытый, JSON-ориентированный стандарт, формализованный в документе RFC 7519, предназначенный для компактного, самодостаточного и проверяемого представления утверждений (claims) между двумя и более доверяющими друг другу сторонами.

JWT не является механизмом аутентификации как таковым — он не проверяет учётные данные, не выполняет вход и не управляет сессиями. Это носитель аутентификационного и авторизационного контекста, позволяющий клиенту и серверу обмениваться информацией, подтверждённой криптографической подписью, с гарантией её целостности и подлинности. Сервер, получив JWT, может независимо убедиться, что:

  • содержимое токена не было изменено после генерации;
  • токен был выдан именно этим сервером (или доверенным удостоверяющим центром);
  • срок действия токена не истёк;
  • утверждения, содержащиеся в нём, соответствуют политике доступа.

Таким образом, JWT служит не столько доказательством личности, сколько доказательством права: он подтверждает, что в определённый момент времени субъект прошёл процедуру верификации и получил от доверенного источника набор утверждений, которые могут быть использованы для последующих решений по авторизации, маршрутизации или учёту активности.

Ключевая особенность JWT — его самодостаточность. В отличие от идентификатора сессии, который требует обращения к внешнему хранилищу для получения контекста, JWT содержит в себе и метаданные (в заголовке), и полезную нагрузку (в теле), и механизм проверки подлинности (в подписи). Это позволяет каждому получателю токена — будь то основной API-шлюз, микросервис или сторонний партнёр — независимо валидировать и интерпретировать его содержимое, не прибегая к централизованному хранилищу. Такая автономность особенно ценна в архитектурах, ориентированных на микросервисы, API-first-подход и федерацию идентификации (например, OpenID Connect), где минимизация межкомпонентных зависимостей и задержек критична для производительности и отказоустойчивости.

Важно подчеркнуть, что JWT — это чётко структурированный объект, следующий строгим правилам кодирования и композиции. Его структура состоит из трёх сегментов, каждый из которых имеет своё функциональное назначение и формат представления, а именно: заголовок (header), полезная нагрузка (payload) и подпись (signature). Эти компоненты, последовательно закодированные в URL-safe Base64Url и объединённые символом точки (.), образуют компактную, транспортно-нейтральную строку, пригодную для передачи в HTTP-заголовках, URL-параметрах или теле запроса. Ни одна из частей не является опциональной в подписанном JWT (JWS — JSON Web Signature); утверждения о «безопасных», но неподписанных токенах (например, с "alg": "none") носят скорее академический характер и в продакшен-средах категорически недопустимы.

Структура JWT​

JWT состоит из трёх частей, разделённых точками (.):

  1. Header — метаданные токена. Содержит тип токена ("typ": "JWT") и алгоритм подписи ("alg"). Пример:

    {
      "alg": "HS256",
      "typ": "JWT"
    }

  2. Payload — тело токена. Содержит утверждения (claims). Существуют три типа claims:

    • Зарезервированные (iss, exp, sub, aud и др.) — стандартизированы, но не обязательны.
    • Публичные — согласованные между сторонами (например, role, department).
    • Приватные — специфичные для приложения (например, user_id, is_premium).

    Пример payload:

    {
      "sub": "1234567890",
      "name": "Тимур Тагиров",
      "role": "admin",
      "exp": 1730000000
    }

  3. Signature — криптографическая подпись, гарантирующая целостность токена. Формируется путём:

    • Кодирования header и payload в Base64Url;
    • Конкатенации их через точку;
    • Подписи полученной строки с использованием секретного ключа (HMAC) или закрытого ключа (RSA/ECDSA).

    Пример подписи (для HMAC):

    HMACSHA256(
      base64UrlEncode(header) + "." + base64UrlEncode(payload),
      secret
    )

Результирующий токен выглядит так:
xxxxx.yyyyy.zzzzz

Применение JWT​

  1. Аутентификация
    После успешного входа пользователь получает JWT. При последующих запросах он передаёт токен (обычно в заголовке Authorization: Bearer <token>). Сервер проверяет подпись и срок действия, после чего считает запрос аутентифицированным.

  2. Авторизация
    Роли и разрешения кодируются в payload. Например, наличие "role": "admin" позволяет контроллеру разрешить доступ к защищённому эндпоинту.

  3. Единый вход (SSO)
    JWT может использоваться как токен обмена между сервисами в рамках единой экосистемы. Например, сервис аутентификации генерирует токен, который принимают все микросервисы.

Ограничения и риски​

  • JWT не отменяется
    Поскольку JWT stateless, его нельзя инвалидировать до истечения срока действия (exp). Решения:

    • Использовать короткий срок жизни (например, 15 минут) и пару access/refresh tokens;
    • Вести чёрный список недействительных токенов (например, в Redis).

  • Хранение на клиенте
    Хранение JWT в localStorage подвержено атакам XSS; в HttpOnly cookie — атакам CSRF. Оптимальный выбор зависит от архитектуры и уровня угроз.

  • Подделка токена
    Если сервер использует слабый или утечку секретного ключа, злоумышленник может сгенерировать валидный JWT. Требуется тщательное управление ключами.

4. Валидация входных данных и управление доверием​

Аутентификация и авторизация не защищены, если входные данные не проходят строгую валидацию. Уязвимости типа insecure direct object reference (IDOR) или injection часто возникают из-за отсутствия проверки входных параметров.

Белый и чёрный списки​

  • Белый список (allowlist) — явное разрешение только известных, ожидаемых значений.
    Пример: разрешить выбор роли только из ["user", "moderator", "admin"].

  • Чёрный список (blocklist) — попытка запретить опасные значения. Не рекомендуется, так как невозможно перечислить все возможные векторы атаки.

Белый список — единственный надёжный подход в критичных местах (ролях, путях файлов, идентификаторах).

Библиотеки валидации​

Для обеспечения типобезопасности и валидации структуры данных используются специализированные библиотеки:

  • Python: Marshmallow — декларативная валидация и сериализация объектов.
  • Node.js: Joi (ныне @hapi/joi) или Zod — строгая схема валидации с поддержкой кастомных правил.
  • C#: встроенные механизмы Data Annotations ([Required], [StringLength]) и библиотеки вроде FluentValidation.
  • Java: Bean Validation (@NotNull, @Pattern) + Hibernate Validator.

Пример на Python (Marshmallow):

from marshmallow import Schema, fields

class LoginSchema(Schema):
    username = fields.Str(required=True, validate=validate.Length(min=3, max=32))
    password = fields.Str(required=True, validate=validate.Length(min=8))

Такой подход предотвращает передачу неожиданных или вредоносных данных на уровень аутентификации.

5. Управление сессиями и stateful-подход​

Хотя JWT популярен, сессионная аутентификация остаётся актуальной, особенно в монолитных веб-приложениях.

Как работает сессия​

  1. Пользователь отправляет логин и пароль.
  2. Сервер проверяет учётные данные.
  3. При успехе создаётся объект сессии на сервере (в памяти, Redis, БД).
  4. Клиенту возвращается session ID (обычно в Set-Cookie).
  5. При последующих запросах браузер автоматически отправляет cookie с session ID.
  6. Сервер находит сессию по ID и проверяет её валидность.

Преимущества сессий​

  • Возможность мгновенной отмены (удаление из хранилища).
  • Отсутствие передачи чувствительных данных клиенту.
  • Встроенная защита от XSS при использовании HttpOnly cookie.

Недостатки​

  • Требует stateful-архитектуры (сложнее масштабировать).
  • Неудобно в мобильных и SPA-приложениях без дополнительной обвязки.

6. Готовые фреймворки: Identity, Keycloak, Auth0​

ASP.NET Core Identity​

Встроенная система управления пользователями в .NET. Включает:

  • CRUD-операции над пользователями и ролями.
  • Хранение в таблицах: AspNetUsers, AspNetRoles, AspNetUserRoles.
  • Поддержку внешних провайдеров (Google, Facebook).
  • Встроенную двухфакторную аутентификацию (2FA) через TOTP или SMS.

Пример включения 2FA:

// Включение 2FA
await _userManager.SetTwoFactorEnabledAsync(user, true);

// Генерация секретного ключа для Google Authenticator
var key = await _userManager.GetAuthenticatorKeyAsync(user);
if (string.IsNullOrEmpty(key))
{
    await _userManager.ResetAuthenticatorKeyAsync(user);
    key = await _userManager.GetAuthenticatorKeyAsync(user);
}

Проверка TOTP-кода:

var isValid = await _userManager.VerifyTwoFactorTokenAsync(
    user, _userManager.Options.Tokens.AuthenticatorTokenProvider, code);

Keycloak​

Open-source Identity и Access Management (IAM) сервер. Поддерживает:

  • OAuth 2.0, OpenID Connect, SAML.
  • RBAC, fine-grained permissions.
  • Адаптеры для Java, JavaScript, .NET, Python.
  • UI для управления пользователями и ролями.

Auth0 и Okta​

Облачные решения с минимальной настройкой. Подходят для стартапов и SaaS-продуктов. Предоставляют:

  • Готовые экраны входа/регистрации.
  • Аналитику аутентификации.
  • Поддержку социальных провайдеров.
  • Управление MFA, блокировку брутфорса, anomaly detection.

7. Единый вход (Single Sign-On, SSO)​

Single Sign-On (SSO) — архитектурный паттерн, позволяющий пользователю аутентифицироваться один раз и получить доступ к множеству взаимодействующих систем без повторного ввода учётных данных.

Принцип работы​

  1. Пользователь пытается получить доступ к приложению A.
  2. Приложение A перенаправляет его на Identity Provider (IdP).
  3. Если пользователь не аутентифицирован в IdP — ему предлагается войти.
  4. После успешной аутентификации IdP генерирует утверждение (assertion) и перенаправляет пользователя обратно в приложение A с этим утверждением.
  5. Приложение A проверяет подлинность утверждения и создаёт локальную сессию.

Стандарты SSO​

  • SAML (Security Assertion Markup Language)
    XML-ориентированный стандарт, доминирующий в корпоративном секторе (особенно в интеграциях с Microsoft, SAP, Salesforce). Обеспечивает надёжную передачу атрибутов и поддержку федеративной идентификации.

  • OpenID Connect (OIDC)
    Современный, JSON/REST-ориентированный стандарт на базе OAuth 2.0. Широко используется в облачных и веб-приложениях. Проще в реализации, чем SAML, и лучше подходит для SPA и мобильных клиентов.

  • OAuth 2.0 как основа
    Хотя OAuth 2.0 изначально не предназначен для аутентификации, в связке с OIDC он становится полноценным SSO-решением. Провайдеры (Google, Microsoft, GitHub) предоставляют OIDC-эндпоинты (/.well-known/openid-configuration).

Преимущества SSO​

  • Улучшение UX: пользователь входит один раз.
  • Централизованный контроль: администратор управляет доступом в одном месте.
  • Снижение рисков: меньше паролей → меньше утечек.
  • Упрощённый аудит и логирование.

Риски​

  • Единая точка отказа: компрометация IdP даёт доступ ко всем системам.
  • Сложность отмены доступа: требуется своевременная синхронизация статуса учётной записи.

8. Интеграция аутентификации и авторизации в разные типы приложений​

8.1. Веб-приложения​

  • Традиционные (server-rendered)
    Используют сессионную аутентификацию с HttpOnly cookie. CSRF-токены обязательны. Авторизация реализуется через middleware (например, [Authorize] в ASP.NET, @login_required в Django).

  • SPA (React, Angular, Vue)
    Чаще используют токен-ориентированный подход (JWT). Токен хранится в памяти (не в localStorage) для защиты от XSS. Авторизация на фронтенде — декоративна; окончательная проверка всегда на бэкенде.

  • API-first архитектура
    Все эндпоинты защищаются через заголовок Authorization: Bearer <token>. Используются кастомные middleware или библиотеки (express-jwt, Flask-JWT-Extended, Microsoft.AspNetCore.Authentication.JwtBearer).

8.2. Десктопные приложения​

  • Native-приложения (WPF, WinForms, Electron)
    Аутентификация часто реализуется через браузерную перенаправляющую модель (OAuth 2.0 Authorization Code + PKCE). Это безопаснее хранения логина/пароля в приложении.
    После получения токена он сохраняется в защищённом хранилище ОС: Windows Credential Vault, Keychain (macOS), libsecret (Linux).

  • Автономные системы
    В отсутствие сети может применяться локальная аутентификация (например, хэши паролей в зашифрованном файле), но с ограничениями: нет централизованного управления, нет SSO.

8.3. Мобильные приложения​

  • OAuth 2.0 + PKCE — рекомендуемый стандарт (RFC 7636). Предотвращает перехват authorization code.
  • Biometric Unlock — после первоначального входа пользователь может разблокировать приложение отпечатком, но JWT/refresh token остаются в защищённом хранилище (Android Keystore, iOS Secure Enclave).
  • Refresh Tokens — критически важны из-за долгой сессии. Должны быть привязаны к устройству и иметь механизм отмены.

9. Практические рекомендации по проектированию системы доступа​

  1. Разделяйте аутентификацию и авторизацию
    Не смешивайте проверку личности и проверку прав. Используйте отдельные компоненты (IdP и Policy Engine).

  2. Минимизируйте привилегии (Principle of Least Privilege)
    Пользователь должен получать только те права, которые необходимы для выполнения задачи.

  3. Никогда не храните пароли в открытом виде
    Используйте адаптивные хэш-функции: Argon2, scrypt, bcrypt. Не используйте MD5 или SHA1.

  4. Используйте HTTPS повсеместно
    Без TLS любой механизм аутентификации уязвим к перехвату.

  5. Внедряйте многофакторную аутентификацию (MFA)
    Особенно для администраторов и привилегированных учётных записей.

  6. Ведите аудит действий
    Логируйте входы, выходы, изменения прав, неудачные попытки входа. Это необходимо для расследования инцидентов.

  7. Избегайте самописных криптографических решений
    Используйте проверенные библиотеки и протоколы. «Security through obscurity» не работает.

  8. Тестируйте на уязвимости
    Регулярно проводите аудиты: проверяйте на IDOR, broken access control (OWASP Top 10), утечки токенов.